ソフトウェアアーキテクチャの基礎輪読会 17章
日付：11/27
章：17章
調査者：takasshii.icon
要約
マイクロサービスアーキテクチャ
歴史
マイクロサービスアーキテクチャは2014年3月のブログ記事から広がった 普通は多くの人が共通して使った後にパターン化されて命名されるため、珍しい
コンテキストごとで分離する図↓
https://cdn-ak.f.st-hatena.com/images/fotolife/l/little_hands/20171128/20171128084349.png
分散アーキテクチャ
各サービスは独自のプロセスで実行される
ここでいうプロセスは、現在では仮想マシンやコンテナを指す
プロビジョニング（ストレージの仮想化など）によって分散のメリットが大きくなってきた
サービスごとにプロセスが分かれている図↓
https://cdn-ak.f.st-hatena.com/images/fotolife/l/little_hands/20171206/20171206232814.png
プロセスを分離するメリット
障害やリソースの要求が他のサービスに影響を与えるリスクが減る
サービスが独立するため
リソース（CPU, メモリ, ストレージ）を効率化する
プロセスごとにリソースが割り当てられるため
プロセスが必要としている量に応じてリソースを消費するため
プロセスを分散するデメリット
パフォーマンスが悪くなる
プロセス（サービス）間通信に時間がかかる
REST APIやプロセス間通信の通信時間がかかるため
セキュリティ検証に時間がかかる
リソースが分離しているため、アクセスして良いかの検証に時間がかかるため
コンテキストで分離する
コンテキストによって分離されるので、結合より重複を好む
「マイクロ」とあるが、細かすぎるサービスを作るとデメリットが大きくなってしまうため適切な分離の粒度が必要
分離のガイドライン
目的によって分離する
ドメインの機能によって分離する
トランザクションによって分離する
トランザクションは分散アーキテクチャで問題を生む
トランザクションの分離を回避できるように分離する
様々なサービスと通信を行うと無駄な通信（オーバーヘッド）が発生する
広い部分で通信を行っている場合は、そのサービスをまとめる
データ分離
マイクロサービスの特徴はサービスごとにDBを分離すること
DBを複数用意する
従来は1つのRDBを信頼できる唯一の情報源としていた
マイクロサービスは複数のDBがあるため、唯一の情報源を新たに作る必要がある
方法1. あるドメインを信頼できる唯一の情報源とする
あるドメインを信頼できる唯一の情報源とし、そこからデータを取り出すことで達成する
方法2. DBのレプリケーション（複製）やキャッシュを作成する
複製して整合性を保つことで、常に信頼できる情報源にする
API層
API層は使われることが多いが必須ではない
注意点
API層をメディエーターやオーケストレーションツールとして使ってはいけない
メディエーターを使う場面は、技術によって分割されている場面
マイクロサービスはドメインによって分割されているのでメディエーターはいらない
再利用が必要なものはどうする？？
マイクロサービスは結合より重複を好む
サイドカーパターンを使用する
運用面であれば、運用に関する機能をまとめて、各サービスに配置する
サービスディスカバリーを使用してサービスを制御する方法もある
サービスディスカバリーはサービスの位置を教える
API層からサービスディスカバリーを制御する
フロントエンド
フロントエンドもマイクロサービス化？
制約で難しいこともあるため, する場合としない場合がある
モノリシックなUI
モノリシックなUIがAPI層を通してマイクロサービスのバックエンドを呼び出す
マイクロフロントエンド
バックエンドサービスと対応したコンポーネントをUIに配置する
フロントからバックエンドまで全ての境界を明確に分離できる
Reactはそのフレームワークの一つ
iNoma.iconなるほど
通信
プロトコルを意識した異種間相互通信性を利用する
標準化されたプロトコルを使用する
技術スタックが異種であってもサポートする必要がある
サービスが互いに呼び合う相互運用性をサポートしていないといけない
コレオグラフィ
概要
ブローカー型のイベント駆動アーキテクチャと同じ通信スタイル
中央のメディエーターが存在しない
マイクロサービスとブローカー型は似ており、共生する
コレオグラフィのイベント制御
最初に呼び出されたサービスがメディエーターとして機能する
複雑になる
複雑なビジネスプロセスにオーケストレーションを用いる
複雑なビジネスプロセスにはメディエーターを作成する
サービス間に結合が生じるがわかりやすくなる
トランザクションとサーガ
サービス間のトランザクション調整が問題になることがある
トランザクションを避けるために
サービスを超えてトランザクションを構築しない
マイクロサービスの分離の原則に違反する
コンポーネントの粒度を見直す
トランザクションがサービスを跨ぐときは粒度が細かすぎる
例外
ex.
アーキテクチャ特性が全く違う, 2つのサービスにまたがるトランザクションの場合
トランザクションに関するサービスを調整するメディエーターサービスを作成する
そのサービスがトランザクションを処理し、各サービスを呼び出す
トランザクションが失敗したときは, 関わった処理全てを取り消す
全てが成功するまで, 保留状態にしておくことで実装する
非同期リクエストで新しいリクエストが発生した場合に非常に複雑になる
トランザクション操作ごとに実行と取り消しを実装する方法もある
取り消し操作の実装やテストが非常に大変になる
実装が非常に複雑になるため、可能な限り避けたい
アーキテクチャ特性の評価
table:サービスベースアーキテクチャ
分割タイプ ドメイン
量子数 1(モノリシック)以上
デプロイ容易性 ☆☆☆☆
弾力性 ☆☆☆☆☆
進化性 ☆☆☆☆☆
耐障害性 ☆☆☆☆
モジュール性 ☆☆☆☆☆
全体的なコスト（の安価さ） ☆
パフォーマンス ☆☆
信頼性 ☆☆☆☆
スケーラビリティ ☆☆☆☆☆
シンプルさ ☆
テスト容易性 ☆☆☆☆
応用
code:sample.kt
質疑応答